Cross-domain access control

ABSTRACT

The present invention provides systems and methods of cross-domain access control in which a client node ( 250 ) sends a request ( 250 ) for a resource to a resource server ( 260 ). In response, a local proxy server ( 270 ) automatically obtains a ticket having a revocation status ( 275 ) and forwards the ticket ( 275 ) to an authorization server ( 280 ) that communicates with the resource server ( 260 ) regarding access.

[0001] This application claims the benefit of U.S. utility patentapplication Ser. No. 60/246936 filed on Nov. 10, 2000 incorporatedherein by reference in its entirety.

FIELD OF THE INVENTION

[0002] The field of the invention is network access control.

BACKGROUND OF THE INVENTION

[0003] Cryptography is used to enhance the security of electroniccommunications between computers. One cryptographic technique involvesuse of asymmetric keys to encrypt, decrypt, and identify senders. Such atechnique typically employs a public key to encrypt a communication orverify a digital signature and a secret or private key for signing anddecrypting communications. While the use of asymmetric keys providessome degree of security against unauthorized viewing and use of thecommunication, there are problems associated with authentication of theparties.

[0004] A trusted certificate authority (CA) may solve authenticationproblems as to the identity of the sender by issuing a digitalcertificate. A digital certificate typically contains the certificateholder's name and public key, the CA's name and digital signature, avalidity period and a serial number. If the digital signature is validand if the CA is trustworthy, the recipient can generally trust that thesender identified in the certificate holds the private key correspondingto the public key in the certificate. To send a relatively securemessage, a sender encrypts the message using the user's public key andtransmits the message to the user. The message can be decrypted only bythe user's private key. Thus, the identity of the sender by a trusted CAis critical to the security of the communication.

[0005] A further authentication process involves the sending partydigitally signing a communication by encrypting the communication withthe sending party's private key. The communication can only be decryptedby using the sending party's public key. Thus, the recipient of thecommunication can trust that the communication came from the sendingparty.

[0006] Within large organizations, an authentication hierarchy may bedesirable that corresponds with the levels of the organization. Eachlevel of the organization could have its own private key, and thereforeany employee at that particular level would have the same access. Whilean authentication hierarchy may create some scalability in thatmaintenance of private keys is relatively less intensive, problems withauthentication persist, particularly with respect to latency andresource utilization involved in checking revocation lists.

[0007] Revocation lists exist partly to accommodate for certificatesthat have been compromised and are no longer valid. Prior to allowingaccess or accepting a communication from a certificate holder, anauthorization entity typically checks a revocation list to ensure thecertificate has not been revoked. To circumvent at least some of theproblems associated with checking revocation lists, U.S. Pat. No.6,301,658 to Koehler (October 2001) teaches a verification server thatassigns a timestamp to a certificate indicating when the certificate waslast authenticated. The verification server incrementally updates thelevels of authority. Revocation lists having information on revokedcertificates, are only accessed when the timestamp indicates thecertificate is out of date. The need to access revocation lists,however, still exists as do problems associated with accessing therevocation lists.

[0008] U.S. Pat. No. 5,903,651 to Kocher (May 1999) teaches thatdependency on revocation lists may be reduced to some degree by a methodthat reduces the scope of the search needed to determine whether acertificate has been revoked. Even here, problems related to networklatency persist since the revocation list still needs to be accessed.

[0009] Kerberos is a network authentication protocol developed by M.I.T.(see http://web.mit.edu/kerberos/www/) that teaches a method for unitarylogin, wherein a single authentication server identifies a user once foraccess to an application servers. Kerberos uses symmetric keys only,after the first identification step that may use either a password or auser certificate. However, Kerberos is deficient in that it does notallow a standard web browser to be used by the client for access to theapplication server, or convey the user certificate to the applicationserver for encryption or access control purposes. Also, Kerberosrequires more cross-domain communication (which Kerberos calls“inter-realm”) when the client and server are not in a common domain.

[0010] Thus, there is a need for methods and devices that cansubstantially circumvent revocation lists while maintaining theintegrity of digital certificates and using a web browser to obtain aresource.

SUMMARY OF THE INVENTION

[0011] The present invention provides systems and methods ofcross-domain access control in which a client node sends a request for aresource to a resource server. In response, a local proxy serverautomatically obtains a ticket having a revocation status and forwardsthe ticket to an authorization server that communicates with theresource server regarding access.

[0012] In a further aspect, a privilege granting authority may includeprivilege related information in the ticket. Such privilege informationmay be used by an authorization server to determine whether the clientnode is within the class of users that have access to the particularresource.

[0013] Various objects, features, aspects and advantages of the presentinvention will become more apparent from the following detaileddescription of preferred embodiments of the invention, along with theaccompanying drawings in which like numerals represent like components.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014]FIG. 1 is a schematic of a prior art system of access controlusing a revocation list.

[0015]FIG. 2 is a schematic of a system of access control.

[0016]FIG. 3 is a block diagram of a method of access control.

DETAILED DESCRIPTION

[0017] Referring first to FIG. 1, a prior art system 100 generallyincludes a client domain 110 and a server domain 120. The client domain110 has a work station 130 and a privilege granting authority 150. Onthe server domain 120 is a resource server 140.

[0018] The work station 130 may send a request 135 to a resource server140. The request is frequently for a web page (e.g. an HTML form), andthe request may include a digital certificate (not shown) that theresource server 140 uses to grant access to the resources (not shown).

[0019] The resource server 140, in need of a revocation status of thecertificate, communicates with the privilege granting authority 150. Theprivilege granting authority 150 (e.g. ValiCert™), in this case, storesthe revocation list (not shown) including identities of certificatesthat have been revoked. Upon receiving the request for the revocationstatus, the privilege granting authority 150 must perform thecalculations that enable return of a revocation status to the resourceserver 140.

[0020] Because communication traverses a path between different domains(i.e. client domain 110 and server domain 120), network latency andbandwidth problems may create a lag in the work station 130 receivingthe resource.

[0021]FIG. 2, is a system 200 also having a client domain 210 and aserver domain 220, however in the embodiment depicted by FIG. 2, accessto a revocation list has been obviated.

[0022] As defined herein, a “domain” is a group of devices that areadministered as a unit with a common certificate authority. Within theInternet, domains are defined by the IP address. As such, “clientdomain”, and “client side” refer to those devices on that are on thedomain of the device requesting content. Additionally, “local” as usedherein refers to the domain requesting the content.

[0023] In order for a server in one domain to identify a client fromanother domain, the client may present a cross certificate (e.g. inX.509 format) that is anchored by a signature known to the server. Thisimplies that there is likely, but not necessarily, a cross certificate235 for a certificate authority in the client domain, CA1 230, that issigned by a certificate authority in the server domain, CA2 240, or by aknown commercial CA (e.g. Verisign™). Such a cross certificatepreferably also contains a public key. In a preferred embodiment, atrusted certificate authority is a mutually non-resident certificateauthority meaning that the certificate authority that issues the crosscertificate does not reside on both the client domain 210 and the serverdomain 220, although it may reside on either. In accordance with thedefinition set forth above, a mutually non-resident certificateauthority may reside on a third party domain (not shown) exclusive ofboth the client domain 210 and the server domain 220.

[0024] In a preferred class of embodiments, a cross certificate isestablished in the client domain 210 to enable secure communicationsbetween a work station 250 and a resource server 260. A work station 250may be any node or combination of nodes that requests informationincluding known desktop computers, PDAs, cellular phones, and such.

[0025] A request 255, and subsequent return of the resource, likelyutilizes a known web browser such as Internet Explorer and NetscapeNavigator. A request 255 preferably includes the communication of adigital certificate or cross certificate to the resource server. Whileit is contemplated that a request 255 will utilize a web browser andrequest a web page (i.e. HTML document), it should be appreciated that arequest may utilize other manners of transfer and request otherresource. For example, using a file transfer protocol (FTP) to obtainprogram source code or using simple mail transfer protocol (SMTP) toobtain e-mail files and attachments. A request 255 typically originatesfrom a client domain 210 and terminates at a server domain 220.

[0026] With respect to authorization, a request 255 may include a simpleor structured authorization (not shown). A simple authorization placesrelatively more computational burden on the user (client domain) while astructured authorization places relatively more computation burden onthe server (server domain).

[0027] A simple authorization is preferably a digital certificatecontaining information needed by a resource server 260 including a shortvalidity period and a digital signature of CA1 230. CA1 is trusted bythe resource server 260 to ascertain that a certificate has not beenrevoked.

[0028] A structured authorization includes at least one pre-existingpublic key certificate, and for each certificate, a “hash-chain proof”of non-revocation. A hash-chain proof is a type of digitally signedcertificate that can be produced without per-request signaturecomputation. Instead, a signature is computed periodically on a form ofa revocation list. A structured privilege generally represents a “group”or “role”. A user organization may define a hierarchy of groups andassociated roles. A hierarchy is typically known to a privilege grantingauthority which may encode it either as a table to support simpleauthorizations or by using subgroup relation certificates to supportstructured authorizations.

[0029] A resource server 260 is preferably a node having the requestedresource. It is contemplated that the requested resource may bedistributed over more than one resource server, and as such a request255 may be directed to more than one resource server. A resource server260 is typically controlled by a party desiring to facilitate securecommunications by utilizing public certificates. Contemplatedcontrolling parties include a bank, a product or service vendor, and anauction site.

[0030] A proxy 270 is software residing on the client domain 210 thatoperates to detect a request 255 from a work station 250. Detection mayinclude overhearing, or intercepting a request 255. It is alsocontemplated that a duplicate request (not shown) may be issued to theproxy 270. Regardless of the manner used to detect a request, a proxy270 becomes aware that a request including a public certificate has beenmade. A proxy 270 automatically (e.g. without any manual impetus) issuesa ticket request to a privilege granting authority 290, that is,preferably local. Upon receipt of a ticket 275, a proxy server 270 mayforward the ticket to an authorization server 280 on the server domain220.

[0031] A privilege granting authority 290 preferably checks a revocationstatus and returns a ticket 275. Checking a revocation status generallyinvolves accessing a certificate revocation list (CRL) stored on adatabase and matching a certificate associated with the work station 250to the set of revoked certificates. If a match occurs, a ticket may notbe issued. Alternatively, a ticket may be issued, but such ticket mayindicate that the certificate has been revoked. A privilege grantingauthority 290 may further maintain an access control list (ACL), and insuch a case the privilege granting authority 290 checks whether theclient has the access it is requesting.

[0032] A ticket 275 is preferably a certificate having a short lifetime,but it may contain additional information such as privilege informationand such. A short lifetime is contemplated to be up to 24 hours, but ispreferred to be less than 2 hours, and more preferred to be 30 minutesor less. A short lifetime represents a period of non-revocation. Thus, aparty receiving ticket with a short lifetime can be reasonably sure thatthe associated certificate has not been revoked.

[0033] An authorization server 280 receives the ticket 275 that has atleast a short lifetime (period of non-revocation) and may also haveaccess control information (privilege status information). Anauthorization server 280 receives a ticket 275 that has been forwardedby the proxy 270, and in response to a request for non-revocation statusfrom the resource server 260, the authorization server 280 may provideeither the ticket 275 or information indicating a revocation status andaccess control (e.g. group privileges). The ticket and/or informationare used by the resource server 270 to grant or deny access to aresource requested by the work station 250. It should be realized thatresource servers no longer need to store access control lists withentries for individual users in order to determine whether a particularrequest has access to a particular resource. Access control lists may belimited to group or role privilege entries.

[0034] In FIG. 3, a method of cross domain access control includes: 10 aclient node requesting a resource from a server side node, the requestmay further include a digital certificate and privilege information, andpreferably utilizes a web browser; 20 a server node requesting arevocation status (preferably the request is made to an authenticationserver on the same domain as the server node); 30 a client proxy serverautomatically sending a ticket request to a client side privilegegranting authority; 40 sending a ticket to the proxy server (preferablysent by a privilege granting authority); 50 forwarding the ticket to aserver side authorization server (preferably forwarded by a privilegegranting authority, but may also be sent by a privilege grantingauthority or some other node on the client domain); 60 responding to therevocation status request by using the ticket (preferably anauthorization server responds to the request, and such use of the ticketmay include simply forwarding the ticket to the resource server); and 70server node granting access based on the ticket (may include grantingaccess based on privilege information and non-revocation status).

[0035] Thus, specific embodiments and applications of cross domainaccess control have been disclosed. It should be apparent, however, tothose skilled in the art that many more modifications besides thosealready described are possible without departing from the inventiveconcepts herein. The inventive subject matter, therefore, is not to berestricted except in the spirit of the appended claims. Moreover, ininterpreting both the specification and the claims, all terms should beinterpreted in the broadest possible manner consistent with the context.In particular, the terms “comprises” and “comprising” should beinterpreted as referring to elements, components, or steps in anon-exclusive manner, indicating that the referenced elements,components, or steps may be present, or utilized, or combined with otherelements, components, or steps that are not expressly referenced.

What is claimed is:
 1. A system of cross-domain access controlcomprising: a client domain having a work station, a proxy server, and aprivilege granting authority; and a server domain having a resourceserver, and an authorization server, wherein: the work station sends arequest for a resource to the resource server, the request for theresource including a digital certificate; the resource server sends arequest for revocation status to the authorization server in response tothe request for the resource; the proxy server automatically sends aticket request to the privilege granting authority in response to therequest for the resource; the privilege granting authority responds tothe ticket request by sending a ticket to the proxy server; the proxyserver forwards the ticket to the authorization server; and theauthorization server responds to the request for revocation status atleast partially by using the ticket.
 2. The system of claim 1, furthercomprising at least one mutually non-resident certificate authority. 3.The system of claim 1, further comprising a web browser used to accessthe resource server.
 4. The system of claim 1, wherein the digitalcertificate comprises a public key and digital signature.
 5. The systemof claim 1, wherein the privilege granting authority maintains adatabase including privilege status information.
 6. The system of claim5, wherein the ticket comprises the privilege status information.
 7. Thesystem of claim 6, wherein the authorization server determines access atleast in part as a function of the privilege status information.
 8. Thesystem of claim 7, wherein the resource server serves the resource basedat least in part on the privilege status information.
 9. The system ofclaim 1, further comprising a hierarchy of certificate authorities. 10.A system of cross-domain access control having a client domain and aserver domain, comprising: a workstation on the client domain that sendsa request for a resource to a resource server on the server domain; aproxy server programmed to automatically send a ticket request to aprivilege granting authority in response to the request for theresource; and an authorization server that receives the ticket, andresponds to a request for revocation status from the resource server, atleast partially by using the ticket.
 11. The system of claim 10, furthercomprising a web browser used to access the resource server.
 12. Thesystem of claim 10, wherein the ticket comprises privilege statusinformation.
 13. The system of claim 12, wherein the resource serveruses the privilege status information to determine privileges.
 14. Asystem of cross-domain access control having a client domain and aserver domain, comprising: a workstation on the client domain that sendsa request for a resource to a resource server on the server domain; anda proxy server programmed to automatically send a ticket to the resourceserver in response to the request for the resource.
 15. A method ofcross-domain access control comprising: a client side node requesting aresource from a server side node, the request including a digitalcertificate; the server side node requesting a revocation status; aclient side proxy server automatically sending a ticket request to aclient side privilege granting authority; sending a ticket to the proxyserver; forwarding the ticket to a server side authorization server; andresponding to the revocation status request by using the ticket.
 16. Themethod of claim 15, further comprising the server side node grantingaccess based on the ticket.
 17. The method of claim 16, wherein the stepof granting access is based at least in part on privilege statusinformation.
 18. A method of cross-domain access control comprising theordered steps of: issuing a request for a resource; overhearing therequest for the resource and automatically issuing a ticket request;issuing a revocation status request in response to the request for theresource; responding to the ticket request by sending a ticket;forwarding the ticket in response to the ticket request; and using theticket at least in part to respond to the revocation status request. 19.The method of claim 18, further comprising granting access to theresource based at least in part on the ticket.
 20. The method of claim19, wherein the ticket comprises privilege information, and the step ofgranting access further comprises analyzing the privilege information.